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ABSTRACT 



The present invention is a software system that detects large 
classes of programming and run-time errors in a computer 
program by emulating the hardware platform and monitor- 
ing the execution of a program and the concurrent data 
manipulation. The software system locates bugs in binary 
object executable programs. Working on the binary object 
executable program at runtime, the tool verifies memory 
references and program implementation by monitoring each 
logical memory access for data. 
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SOFTWARE EMULATING HARDWARE FOR software by checking all data memory accesses made by an 

ANALYZING MEMORY REFERENCES OF A application process running on specific operating systems. 

COMPUTER PROGRAM When an improper behavior is detected by the tool, the tool 

issues an error message identifying the kind of error and 

CROSS-REFERENCE TO RELATED 5 where it occurred. Improper behavior may be any access to 

APPLICATION a logically unallocated region, errors or abuses of the 

This patent application claims the benefit of the filing date dynamic memory allocation protocol, and the like, 

of U.S. Provisional Patent Application Ser. No. 60/165,840, In one aspect, the present invention describes a method 

filed Nov. 16, 1999 and entitled "SOFTWARE EMULAT- for analyzing a computer program for execution on a target 

ING HARDWARE FOR ANALYZING MEMORY 10 hardware platform. The method comprises the steps of 

REFERENCES", the entire contents of which are hereby emulating the target hardware platform by a computer 

expressly incorporated by reference. software; fetching an instruction included in the computer 

program; decoding the fetched instruction; executing the 

FIELD OF THE INVENTION decoded instruction; and monitoring data manipulation by 

The present invention relates to a computer system and 15 tne emulated hardware platform of the executed instruction, 

method for testing and debugging computer programs. More Still other embodiments of the present invention will 

specifically, the present invention is directed to a method and become readily apparent to those skilled in the art from the 

system for emulating hardware for analyzing memory ref- following detailed description. As will be realized, the 

erences. invention is capable of other and different embodiments and 

t-*.™™™™ ^ _ .... , 20 its several details are capable of modification in various 

BACKGROUND OF THE INVENTION resp6Cts> ^ ^ovt depa ^ g fa)m , he spirjt ^ ^ of 

Reliable and successful software is built through sound, the present invention. Accordingly, the drawings and 

efficient and thorough testing. However, software testing is detailed description are to be regarded as illustrative in 

labor intensive and expensive and accounts for a substantial nature and not as restrictive, 
portion of commercial software development costs. At the 

same time, software testing is critical and necessary to BRIEF DESCRIPTION OF THE DRAWINGS 
achieving quality software. Typically, software testing FIG. 1 is an exemplary block diagram for a program under 
includes test suite generation, test suite execution validation, test according to one embodiment of the present invention; 
an regression testing. 30 FIG. 2 is an exemplary flow process of mstmction execu- 
te size and sophistication of computer programs have don according to one embodiment of the present invention; 
substantially increased over time. As a result, the need for ™^ - . . ^ . 
more flexible and sophisticated testing and debugging tools F J°-. 3 15 ™ e * em P l "y fl ° w ■ <* °P«*ation of one 
has also increased. Memory access related errors are one of <<mbodiment *>K™™ '°°L of the present mvention; 
the most important errors which must be watched and 35 

corrected. The current practice for testing and debugging FIG - 4" is an exemplary flow chart of operation of one 
programs include having the compiler output extra instruc- embodiment of the software tool of the present invention, 
tions for debugging purposes or to post-process the object 
files. These approaches require pre-processing of the pro- 
gram which is cumbersome, requires larger storage, and is 4Q The software tool of the present invention is a software 
time consuming. emulation of hardware that analyzes software by checking 

Therefore, what is needed is a test tool for assisting data memory accesses made by an application process 

programmers in testing software programs that is capable of running on specific operating systems such as, Linux x86 or 

directly emulating the preexisting instructions and not other operating systems. The tool emulates a hardware 

inserting (storing) new instructions into (the storage occu- 45 platform and monitors the execution of a program and the 

pied by) preexisting machine code. concurrent data manipulation by the hardware platform. The 

software tool emulates the hardware by maintaining the 

SUMMARY OF THE INVENTION programmer- accessible hardware state as software variables, 

The present invention is a software system that detects aDd bv imitating the programmer-accessible effects of the 

large classes of programming and run-time errors, including 50 hardware circuitry in program logic. In one embodiment, the 

algorithmic anomalies, bugs, and deficiencies in a computer variables include the instruction pointer (program counter), 

program. By emulating the hardware platform and monitor- hardware processor registers, and hardware processor flags 

ing the execution of a program and the concurrent data an£ * condition codes. 

manipulation, the tool helps developers understand how The tool uses software logic to fetch, decode, and execute 

their code behaves while requiring less test preparation time 55 the current instruction, and to advance to the next 

and less storage. The software system locates bugs in binary instruction, following the documented or observed side 

object executable programs. Working on the binary object effects of the hardware. Memory is maintained as memory; 

executable program at runtime, the tool verifies memory the emulator itself occupies address ranges that are not used 

references and program implementation by monitoring each by the program being emulated. In one embodiment, as 

logical memory access for data. The software tool works 60 many as possible of emulator's variables are maintained in 

directly with any executable program, and does not require the hardware to which they correspond, 

source or relocatable object code. This is an advantage when When the tool detects improper behavior, the tool issues 

pieces of the program are provided by others, who may an error message identifying the kind of error and where it 

furnish only "shared libraries" or other forms which are not occurred. Improper behavior may be any access to a logi- 

relocatable object code, and not source code. 65 cally unallocated region, or a read (or modify) access to 

In one embodiment, the software tool of the present bytes which have been allocated but not yet written, 

invention is a software emulation of hardware that analyzes Improper behavior also includes a read operation that 
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fetches uninitialized bytes from memory with the resulting The present invention detects a variety of error categories 

value being logically undefined. Another example of including: 
improper behavior is errors or abuses of the dynamic 

memory allocation protocol, such as attempting to free the Memory corruption/uninitialized memory 

same block twice. 5 Memory leaks 

FIG. 1 is an exemplary block diagram of a test environ- Memory allocation errors 

ment according to one embodiment of the present invention. yQ errors 

A software emulator 12 is included between a program pointer errors 

under test 11 and a hardware processor 13 to provide io 

comprehensive, detailed diagnostic information about the ^ io ° l is ^ ca P able of Panning accounting of 

execution of the program under test. An optional software memory states and accesses. The following table depicts an 

debugger 14 may be used to facilitate interaction with the example for different states and the corresponding accesses. 



user. 



15 



states (below); 




accesses (right) 


Read or Modify Write 


Unallocated 


error: Read before error: Write before 




Allocate Allocate 


Allocated but not 


error: Read before OK; becomes Allocated 


Written 


Write and Written 


Allocated and Written 


OK OK 



The tool also detects memory blocks that have been 
allocated and not freed. Such a memory block is called "in 
use." If a memory block is in use, and is unreachable by 
starting from the stack or statically allocated regions and 

proceeding through already reached allocated blocks, the 2 o 
block is then called a "memory leak." The block could not 
be freed without some oracle to specify its address as the 
parameter to the deallocation routine. A memory leak is 

similar to a "garbage" block in a classical garbage collection r , c A11 A . , . „ „ „ 

u a. .? . • c i* L Examples of Allocators include: malloc, calloc, realloc, 

scheme. At the termination or the application process, the 25 r ... „ _ ' „ ' 

tool reports memory leaks automatically, and reports non- ™™*W> Jibc_mdloc, _ifcc_calloc, Jibe realloc, 

leaked blocks in use if requested, for example, by a com- -^^memakgn, stack growth (push, create frame), _brk, 

mand line option. brk > - sbrk > ^ mma P> md the like ' 

Examples of De-allocators include: free, realloc, _Jibc_ 

Hie tool checks all data memory accesses, whether in the 30 ^ _iibc_rcalloc, _J>rk, brk, _sbrk, sbrk, stack trim (pop, 

application developer's compiled code, language runtime delete frame)j munmapj me ^ 

support routines, archive or shared libraries, and modules r\*u i ^ • i j 

i j j i • t*i_ * i , • i_ • . ^ T Other known functions include: memcpy, memset, 

loaded dynamically. The tool works with existing ELF , , 

* ui ci ti_ c li ,t_ * i * -i memmove, memchr, bcopy, bzero, strcat, strchr, stpepy, 

executable files. Preferably, the tool requires no recompila- A ' . ~ , \ : . , ~ f 

tion and no re-linking. 35 Strcpy > strrcbr 111656 functl0ns are optimized for faster 

performance, and/or to reduce the clutter of multiple error 

The present invention provides diagnosis of each code messages that arise from a single call, and/or to suppress 

problem, including a description of the error the executable « false itiye „ Read before Wfite m s ffom 

location containmg the error, stack trace information, and „■ iUn * „„ r m ♦ u a * 1 

. c . t * jo, j i- r L • r tion sequences that are known to be used to implement 
specific pointers to source code file and line if such infor- 2 4 , . „ . * 
mation was saved when the code was compiled. Hie error *° ^^ocale control, or speculate word-wide read- 
reports help developers find errors more quickly. The inven- mg of byte 

tion operates without modifying source code. The software FIG. 2 is an exemplary flow process of instruction execu- 
tool checks all data memory references made by a process, tion according to one embodiment of the present invention, 
whether in the developer's compiled code, language support ^ The area ?20 to the left side of FIG. 2 shows an instruction- 
routines, shared or archive libraries, or operating system 45 by-instruction flow of execution through Fetch and Decode 
kernel calls. The tool detects and reports reads of uninitial- (block 21), Execute (block 23), and Advance (block 25). As 
used memory, reads or writes that are not within the bounds shown ^ the area to the right side of FIG 2) ^ software 

of allocated blocks, and allocation errors such as memory omn1oW „„f„™„ t „, n »jj V i * n ^ . . 

, . ™ , , i ... . , « , L1 T J emulator performs two additional steps: Pre-Execution 

leaks. The tool works with existing executable programs. In A t . /L1 , , „ ^ . 

most cases, the tool does not Require ^compilation or 50 £™ * g J * ^ Post - ExecUtlon Acc <™g 

re-linking. Furthermore, no changes to environment vari- ( block 24 >' For manv instructions, the effects of Execution 

ables are necessary. A call to the tool, such as the name of can be predicted m advance. Alternatively, the effects of 

the tool, may be added to the beginning of a command line Execution are not relevant to the accounting. Therefore, in 

or other invocation of the application process. It will then one embodiment, all of the accounting (if any) can be 

execute the process and check all the data memory refer- performed in block 22, and not block 24. However, when the 

ences. current instruction is a system call or it controls an external 

Using this software tool does not require running under a device ' wbicb f ° r exam P le transf6rs data of v ^ in ^ len & th > 

debugger; however, the tool works with existing debuggers. some or ^ of the accounting need to occur in block 24. As 

The tool provides an interface to many existing debuggers to 60 shown m FIG * 2 > accounting is performed after 

facilitate interaction with the user for debugging a program execution, when the extent of the effects of execution can be 

under test. The tool provides a programmable interface to its determined. 

error reporting and system call monitoring. An application The tool is capable of finding problems related to memory 
developer can intercept, reformat, and redirect the tool's corruption. Memory corruption is a substantially problem- 
error reports. Local modifications or additional Input/Output 65 atic error, especially if it is disguised. The following is an 
controls (IOCTLs) and other system calls can be handled example which concatenates the arguments given on the 
easily. command line and prints the resulting string. 



04/27/2004, EAST Version: 1.4.1 



US 6,718,485 Bl 



1: /" file: helio.c V 
2: ^include <stdKb.h> 
3: 

4; int main(int argc, char *argv[J 
5:{ 

6: char "sir *» (char *)rnaIloc(16); 

7: int i; 

8: 

9: str[0] = \Q'\ 

10: for (i=0; i<argc; ++i) { 

11: strcat(str, argv[ij); 

12: if (i < (argc -1)) strcat(str, **"); 

13: } 

14: prin tf(" You catered: %s\rT, str); 
15: return 0; 
16: } 



10 



No portion of the stack is considered to be a memory leak. 
Pointers that reside in the stack are one set of "root" pointers 
that are examined during leak detection. Another set of root 
pointers is the collection of mmaped regions from execut- 
able files, shared libraries, or dynamically loaded modules. 

The following example illustrates the code for a second 
version of the "hello" program that uses dynamic memory 
allocation. When a programmer compiles the program and 
runs with the software tool of the present invention, a "Read 
before Write" error at lines 14 and 15 will be reported 
because the first time through the argument loop the variable 
string_so_iar has not been set to anything. 



IS 



20 



25 



30 



35 



When compiled with a typical compiler and run, the 
results are as expected, for example; 
$ cc -g -o hello hello, c 
$ ./hello world 
You entered: ./hello world 
$ ./hello cruel world 
You entered: ./hello cruel world 

If this were the extent of the test procedures, a program- 
mer would probably conclude that this program works 
correctly, despite the fact that it has a very serious memory 
corruption bug. If the programmer executes with the soft- 
ware tool of the present invention, the command tool ./hello 
cruel world, the tool reports an error because the string that 
is being concatenated becomes longer than the 16 characters 
allocated at line 6. Here the tool has found a bug 
automatically, with no additional effort, simply by emulating 
the program. 

Write before Allocate: 4 bytes at 0x08049670; 4 bad 
bytes, first at 0x08049670 
from OxOOOO+strcat line 29 

from 0x004a+main line llfrom OxOOeb+_libc__start_ 
main 

line 78from 0x0021 +.entryfrom 0x3988+sigprocmask 
line 61 

0 bytes beyond block of 16 bytes at 0x08049660 

allocated 1 calls ago (serial 14) 
from OxOOOd+main line 6 

from 0x00eb+ libc_start__main line 78 

from 0x0021+. en try 

from 0x3988+sigprocmask line 61 

The tool also finds all problems related to overwriting 50 
memory or reading past the legal bounds of an object that is 
allocated dynamically (with malloc.) 

The tool is also capable of detecting problems with 
pointer abuse. Problems with pointers are among the most 
difficult encountered by C and C++ programmers. The 
categories of pointer related problems detected by the tool 
include operations on NULL pointers, operations on unini- 
tialized pointers, and operations on pointers that don't 
actually point to valid data at all. 

A pointer is preferably a 32 bit quantity stored at an 
aligned 4 byte boundary. The application may modify the 
low order bits of a pointer (for example, to implement tags 
or "smart pointers") as long as the 32 bit result addresses the 
beginning or interior of the block. Any other manipulation, 
such as flags in hi-order bits, stem-and-leaf storage of 65 
pointer values, etc., results in a pointer to someplace else, 
possibly to a region that the tool considers to be unallocated. 



45 



55 



60 



1: r file: heilo2.c »/ 
2: #include <stdlib.h> 
3: 

4: int main(int argc, char *argv[J) 

6: char "string, *string_so_far, 

7: int i, length - 1; /* Include trailing NUL */ 



9: 

10: 

11: 

12: 

13: 

14: 

15: 

16: 

17: 

18: 

19: 

20: 

21: 

22: 

23: 

24: 

25: 



for (i-0; i<argc; ++i) { 

length +- 1 + strlen(argv[i3); 
string - mallocflength); 

/* Copy the string built so far. */ 
if (string_so_Jar !- (char *)0) { 
strcpy(string, string_so_far); 

} 

else *string - V] 

strcatfstring, argv[i]); 

if (i < (argc-1)) strcatfstring, 

string_so_far = string; 

} 

printf("You entered: %\n'\ string); 

return 0; 

} 



The error diagnostics are: 

Read before Write: 4 bytes at OxbffffcbO; 4 bad bytes, 

first at OxbffffcbO 

from 0x0058+main line 14 

from Ox00eb+__libc_start_main line 78 

from 0x0021+. entry 

from 0x3988+sigprocmask line 61 

OxbffffcbO not within 100 bytes of any allocated block 

Read before Write: 4 bytes at OxbffffcbO; 4 bad bytes, 

first at OxbffffcbO 

from 0x005e+main line 15 

from Ox00eb+_libc_start_main line 78 

from 0x0021+.entry 

from 0x3988+sigprocmask line 61 

OxbffffcbO not within 100 bytes of any allocated block 

In one embodiment, the tool is capable of detecting 
memory leaks. A memory leak occurs when a piece of 
dynamically allocated memory can no longer be freed 
because the program no longer contains any pointers to that 
block. Thus, a memory leak is a block that has been allocated 
and has not been freed. This memory block cannot be 
reached by following a chain of pointers starting from the 
stack or statically allocated regions and going through other 
reachable allocated blocks. This is similar to the definition of 
"garbage" in classic garbage collection. Memory leaks are 
detected when the application calls exit ( ). 

A block that has been allocated, but has not been freed, is 
memory that is "in use," and is reported only if requested by 
the command line parameter in-use-at-exit-1. It can be an 
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interesting and productive exercise to try to write the appli- FIG. 3 is a flow chart of one exemplary operation of the 

cation so that all allocated blocks are "recycled" by freeing software tool of the present invention. As shown, in block 31 

them before exit ( ). This is one general approach to fixing (Create Table of Initial Address Space) a table of access 

memory leaks. A simple example of this behavior can be permissions is constructed according to the operating system 

seen by running the (corrected) "hello2" program with the 5 conventions for initial layout of the address space of a 

arguments: new process. Blocks 32 through 46 indicate the flow during 

i i /h ii i iW • processing of instructions. The general outline of such an 

tooi./neiio^tnisisatest interpreter is given in Donald E. Knuth, The Art of Computer 

If the state of the .program jus prior to execution of line p r0 * mi * vohime 1/Fuodame ntal Algorithms, 

21 (above program) is examined it will be found that the Addison . Wesl 1968> mli 1969y scctioD 1A3 

variable stnng_so_far pomte to the string hello , which it w M ye fo pp .i 9 7-210, section 1.4.3.2 Trace 

was assigned as a result of the previous loop i te *aUon Tlie R(mtm ^ e ^ of ^ ^ h ^ ^ 

variable string points to the extended stnng hello this", ^ fe ^ncc. A special case of a simulator, called a 

which was assigned on this loop iteration. 4 J ^ • n j / u 1 * 

, T „ ,. _f . . , « * • r , trace or momtor routine, is occasionally used to help m 

When bne 21 is executed stnng_so_far-stnng; will deb ^ since it ^ out a step . by ^ tep account of £ ow 

make both variables point to the longer memory block. Once 15 . t * a u u 

1<1( , / * J . . . the simulated program behaves. 

toxs has happened however, there * no remaining pointer ^ presentinveDtionuses ^ slep . by . step information to 

that points to the shorter block. There is now no way that the -, A . , f ; . £ . jj 

r . consult and update a table of memory states for each address 

memory that was previously pointed to by stnne so far • T J , . 

. , . j • • t i it . j tl" • m the memory address space. In one embodiment, the 

can be reclaimed because it u P^anenfly allocated. This is accounti ^ ^ bits for each b , e of lddfess 

belor^ ' ^ Space - 11,6 ^ bits encode four s,ates: 

- * i i j ^„o^,™ rt « „ / 00: byte is allocated and has been written; Reading is OK, 

bytes leaked at 0x08049728 allocated 3 calls ago (serial Writing is OK 

« ~ „ . ... 01: byte is allocated but not yet written; Reading is bad, 

from 0x005e+main lme HfromOxOOeb +__hbc_ Writing is OK. 

s.art_main line 78 from 0x0021 + .entryfrom 0x3988 + 25 u . „ has ..^ ^ M R 

sigprocmask line 61 Writing is bad. 

16 bytes leaked at 0x08049778 10; b te was but ^ freed Readi is ba(J 

allocated 2 calls ago (serial 15) wrfting 

is bad. 

from 0x005e+main line 11 30 states also enco d e which actions are legal. For 

from 0x00eb+_libc_start_main line 78 example, writing a byte is bad if and only if the left bit is a 

from 0x0021 +.entry 1, and writing a byte is OK if and only if the left bit is a 0. 

from 0x3988+sigprocmask line 61 Similarly, reading a byte is bad if an only if either bit is a 1 , 

22 bytes leaked at 0x080497d0 md readin S a Me is OK if and only if both accounting bits 

allocated 1 calls ago (serial 16) 35 are °* ^ accounting bits are preferably stored packed in 

from 0x005e+main line 11 mcmor ?> 50 ? at one of accounting bits cor- 

. ( . responds to four consecutive bytes of address space. The 

from 0x00eb+_libc_start_main line 78 whole amounting table is stored piecewise linear by address, 

from 0x0021+.entry with an mc j ex to the pieces based on high-order bits of the 

from 0x3988+sigprocmask line 61 40 memory address. Pieces which are entirely vacant are 

Errors often occur using dynamically allocated memory. marked in the index (and are not otherwise present), and act 

In many cases, programs continue running after a program- as if all the bits are 11. 

ming error causes serious memory corruption — sometimes The accounting table is organized and encoded to be small 

they don't crash at all. One common mistake that some and to provide fast and efficient answers to the questions "Is 

programmers make is to try to reuse a pointer after it has 45 it bad to Read this memory location?" and "Is it bad to write 

already been freed. This "dangling pointer*' problem often to this memory location?" As long as the answer is "No," the 

goes unnoticed, because many machines and compilers tool proceeds to the next memory location. If the answer is 

allow this particular behavior. The tool detects many "YES," the tool then notifies the user, 

dynamic memory bugs in addition to dangling pointers, In block 32 (Decode Current Instruction) it is determined 

including freeing the same memory block multiple times, so which class (es) of blocks 33 through 37 apply. Also, the 

freeing stack memory (local variables), passing a pointer address and length of the memory regions accessed are 

that doesn't point to the start of a memory block to a delete determined in this block. For instructions which affect 

operator or a free routine, calls to delete or free with NULL memory, blocks 38 through 44 consult the table of memory 

or uninitialized pointers, and passing nonsensical arguments state, and perform the appropriate accounting based on 

to malloc, calloc, re alloc or free. 55 access type. Not shown are some special instructions which 

Preferably, the tool has a programming interface which perform combinations of accesses. In particular, "PUSH 

allows customization and control of error detection and register" is an allocate and then a write, and "POP register" 

reporting, particularly including the monitoring of calls to is a read then a deallocate operation, 

the operating system kernel. One example of customization In block 45, the current instruction is executed as per 

is to report only the first Read before Write which occurs for 60 Knuth (referenced above), and in block 46 the control 

a particular value of the program counter. This can be useful advances to the next instruction, paying particular attention 

when running an existing application for the first time with to JUMP and other transfers of control, 

the tool, to give an overview of behavior that deserves For most instructions, the memory addresses and lengths 

investigation. The file syscalls.c contains conditional com- that are accessed can be determined just before the instruc- 

pilation symbols ONLY__FIRST_BAD__READ_J > ER_ 65 tion is executed, by decoding the instruction and examining 

LOCATION and N_lstONLY which can be used to imple- the values in the machine registers. For privileged 

ment such an overview customization. instructions, such as system calls, the general schema of 
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memory accesses is known in advance, but the numerical 
values might not be known until after the instruction 
executes. For example, a system call to read variable-length 
input from a tele -typewriter specifies the address and maxi- 
mum length of a buffer to receive the data, but the actual size 
of the data that is read from the device is returned as an 
output value from the system call instruction. 

FIG. 4 is a flow chart of one exemplary operation of the 
software tool of the present invention. Similar to block 31 of 
FIG. 3, in block 51 a table of access permissions is con- 
structed according to a given operating system. In block 52, 
similar to block 32, the address and length of the memory 
regions accessed are determined. Blocks 53 to 55 corre- 
sponds to identifying and separating a system call, from the 
Read, Modify, Write, Allocate, Deallocate, and other func- 
tions. As shown, a system call is performed in block 53. In 
order to maintain correct accounting, the system call needs 
to be executed first, as shown in block 54. The actual 
numerical values are obtained for the schema parameters of 
the system call, and then the accounting information is 
updated, as shown in block 55. Because the system call has 
already been executed, execute current instruction step of 
FIG. 3 (block 45 in FIG. 3) is skipped before entering block 
56 and proceeding to next instruction. 

Appendix I describes an annotated sample session using 
one embodiment of the software tool of the present inven- 
tion referred to as "Chaperon." The session is annotated with 
comments, using lines that begin with the symbol '#', and 
using a font with characters of varying width. Literal text, 
either input or output, appears in a font with characters of 
fixed width. The session uses an optional software debugger 
'gdb' to control the hardware, emulator, and program under 
test. Until the line "0x1700 in gdb__setup ( )" 
(approximately three quarters of the way down page App.I- 
1), the session details the setup, initialization, and prepara- 
tion for useful error reports. The remainder of page App.I-1 
illustrates some aspects of how the tool's embodiment of the 
emulator cooperates with the optional software debugger. At 
the middle of page App.I-2, the tool has detected a "Read 
before Write" error. The program under test reads the byte at 
address 0x0807c590 before that byte was written. The first 
trace -back identifies the active subroutines at the time of the 
bad memory access. The error report also identifies that the 
byte at 0x0807c590 is the last byte of a block of 417 bytes 
beginning at address 0x0807c3f0. This block was the block 
most recently allocated, and the trace-back at allocation also 
appears in the error report. The bottom of page App.I-2 and 
top of page App.I-3 show the interaction of the tool with an 
optional software debugger. The tool user (programmer) can 
find out more by looking at variables, parameters, and a 
more-complete trace-back. The middle of page App.I-3 
shows that the program under test completed successfully 
despite the error, and that there were no memory leaks 
during this run. 

It will be recognized by those skilled in the art that various 
modifications may be made to the illustrated and other 
embodiments of the invention described above, without 
departing from the broad inventive scope thereof. It will be 
understood therefore that the invention is not limited to the 
particular embodiments or arrangements disclosed, but is 
rather intended to cover any changes, adaptations or modi- 
fications which are within the scope and spirit of the 
invention as defined by the appended claims. 

What is claimed is: 

1. A method for analyzing a computer program stored in 
a memory, the computer program including a plurality of 
computer executable instructions for execution on a target 
hardware platform, the method comprising: 
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emulating the target hardware platform in computer soft- 
ware that is stored in address ranges of the memory not 
used by the computer program; 

fetching from the memory an executable instruction 
included in the computer program; 

decoding the fetched instruction; 

executing the decoded instruction on the emulated hard- 
ware platform; and 
10 monitoring data manipulation of the executed instruction 
on the emulated target hardware platform. 

2. The method of claim 1, further comprising the step of 
detecting improper behavior by the computer program. 

3. The method of claim 2, further comprising the step of 
15 reporting the improper behavior. 

4. The method of claim 3, wherein the step of reporting 
includes identifying a type of improper behavior and where 
in the computer program the improper behavior occurred. 

5. The method of claim 2, wherein the step of detecting 
20 improper behavior includes detecting access to a logically 

unallocated memory location. 

6. The method of claim 2, wherein the step of detecting 
improper behavior includes detecting read access to bytes 
which have been allocated but not yet written. 

25 7. The method of claim 2, wherein the step of detecting 
improper behavior includes detecting modify access to bytes 
which have been allocated but not yet written. 

8. The method of claim 2, wherein the step of detecting 
improper behavior includes detecting a read operation that 

30 fetches uninitialized bytes from memory with logically 
undefined resulting value. 

9. The method of claim 2, wherein the step of detecting 
improper behavior includes detecting errors of a dynamic 
memory allocation protocol. 

35 10. The method of claim 2, wherein the step of detecting 
improper behavior includes detecting memory blocks that 
have been allocated and not freed. 

11. The method of claim 2, wherein the step of detecting 
improper behavior includes detecting uninitialized memory 

40 locations. 

12. The method of claim 2, wherein the step of detecting 
improper behavior includes detecting memory leaks. 

13. The method of claim 2, wherein the step of detecting 
improper behavior includes detecting I/O errors. 

45 14. The method of claim 2, wherein the step of detecting 
improper behavior includes detecting pointer errors. 

15. The method of claim 1, further comprising the step of 
performing accounting of memory states and accesses. 

16. The method of claim 1, further comprising the step of 
50 interfacing to a debugger to facilitate interaction with a user. 

17. The method of claim 1, further comprising the step of 
creating a table of initial address space according to a 
pre-determined operating system. 

18. A system for analyzing a computer program including 
55 a plurality of computer executable instructions for execution 

on a target hardware platform comprising: 

a memory for storing the computer program and the target 

hardware platform; 
means for emulating the target hardware platform in 
60 computer software that is stored in address ranges of 
the memory not used by the computer program; 
means for fetching from the memory an executable 
instruction included in the computer program; 
65 means for decoding the fetched instruction; 

means for executing the decoded instruction on the emu- 
lated hardware platform; and 
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means for monitoring data manipulation of the executed 
instruction on the emulated hardware platform of the 
executed instruction. 

19. The system of claim 18, further comprising means for 
detecting improper behavior by the computer program. 5 

20. The system of claim 19, further comprising means for 
reporting the improper behavior. 

21. The system of claim 19, wherein the improper behav- 
ior includes read access to bytes which have been allocated 
but not yet written. 10 

22. The system of claim 19, wherein the behavior includes 
detecting uninitialized memory locations. 
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23. The system of claim 19, wherein the improper behav- 
ior includes memory leaks. 

24. The system of claim 19, wherein the improper behav- 
ior includes I/O errors. 

25. The system of claim 19, wherein the improper behav- 
ior includes pointer errors. 

26. The system of claim 18, further comprising means for 
creating a table of initial address space according to a 
pre-determined operating system. 
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